REMARKS 

Presently pending in the current application are claims 1-52. 
35 USC 112 Rejections 

Claim 1 was rejected based on 35 USC 1 12. As will be shown below, Applicant 
believes that the subject matter previously provided in claim 1 was described in the 
specification. As such, Applicant respectfully requests the 35 USC 112 rejection be 
removed. 

35 USC 102(e) Rejections 

Claim 1 was rejected as being anticipated by Bakshi et al. (US 6,772,200). 
Although Applicant does not believe that Bakshi fully teaches or suggests original claim 
1, as previously described, Claim 1 was amended to include the limitations of: selectively 
redirecting the message to the user for display on a message vehicle occurring directly 
from the redirection device to the user without involvement from the destination site. 
Support for these limitations, which are not taught or suggested by Bakshi, can be found 
at least in paragraphs [0057] and [0062] of the instant application: 

[0057] Redirecting device~a device residing in the neighborhood along with the 
cable access concentrator. This product is intentionally located at the edge of the 
network, providing intelligence at the last scalable point in the cable operators' IP 
network (in closest proximity to the user). The number of redirecting devices will 
replicate the number of access concentrators within the network, and the device will 
inter-connect to one of the access concentrator's Ethernet ports, or in a manner as to 
have access to user upstream traffic. This device could be located anywhere in the 
infrastructure where access to user upstream traffic is available, but the closer it is 
located to the user, the greater the possibility for delivering messages due to 
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upstream service outages. In one embodiement, the insertion of the redirecting device 
includes web cache control protocol., switching or redirecting mechanisms in an existing 
ISP router may be utilized. In another example, the redirecting device is insertede in the 
path of web traffic from the user through an ISP. 

[0062] Direct communication with the customer from the transport vendor or ISP 
vendor, independent of the destination sought by the customer and without blocking 
the customer's access to that destination has not been previously developed and, 
therefore, available. However, the services that directly target real-time bulletins can 
provide a mechanism that forges a general-purpose facility and provide this capability. 

Based on the aforementioned remarks and amendments, Applicant believes the 
present invention is in condition for allowance. A Notice of Allowance is therefore 
respectfully requested. 

Previously Presented Claim 1 

Claim 1 was amended to include, among other limitations: 
Communicating real-time to users of an ISP, comprising: 

Accessing by a redirecting device only user upstream traffic from a destination 
site requested by the user; 

Identifying the user by using data available from the user and provider 
infrastructure to provide a fixed identifier based on the accessed user upstream traffic ; 

Providing, by the redirecting device, the fixed identifier to a consolidating and 
management device, wherein the consolidating and management device is separate 
from the redirecting device; 
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If a message for the user is desired, examining, by the redirecting device, the 
accessed user upstream traffic to determine if it is possible to send a redirection, wherein 
the examining occurs without modifying the accessed user upstream traffic; and 

Selectively redirecting the message to the user for display on a message vehicle. 

The Examiner rejected claim 1 by equating "accessing only user upstream traffic" 
as it appears in claim 1 to Bakshi's proxy. As is known, a proxy handles two-way traffic 
(i.e. upstream and downstream traffic). For example, Bakshi states (bolded for 
emphasis), "In the arrangement shown in FIG. 5, transcoding server 34 includes an HTTP 
(HyperText Transfer Protocol) remote proxy 36, capable of accessing network 18 over 
server/network communications link 16. HTTP remote proxy 36 provides functionality 
different from known network proxies, which generally are little more than a conduit for 
requests to, and replies from, external Internet resources, in that it is capable not only of 
examining such requests and replies, but also of acting upon commands in the requests 
by, for example, determining whether or not to transcode content. Moreover, using 
transcoder 20, HTTP remote proxy 36 is capable of changing content received from 
network 18 prior to returning it to a requesting network client 12. 

Conversely, previously presented claim 1 advantageously discloses accessing 
only user upstream traffic, providing a fixed identifier based on the accessed user 
upstream traffic, examining the accessed user upstream traffic without modifying the 
accessed user upstream traffic. 



13 



Conclusion 

Applicant believes claim 1 is not taught or suggested by Bakshi and thus is in 
condition for allowance. As such, Applicant respectfully request claim 1 as well as all 
claims that depend from claim 1 to be passed to allowance. 

If the Examiner has any other matters which pertain to this Application, the 
Examiner is encouraged to contact the undersigned to resolve these matters by 
Examiner's Amendment where possible. 

Respectfully Submitted, 

/Raffi Gostanian/ 

Raffi Gostanian, Jr. 
Registered Patent Agent 
Reg. No. 42,595 

Date: 05/12/2009 

RG & Associates 

1103 Twin Creeks, Ste. 120 

Allen, TX 75013 
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